@database 003a6898-0 @master CC_Main.guide @$VER: 1.0 @node "Main" "No title" @{b} CpuControl V1 Copyright 1995 by Oliver Goss Release 1.05 / 25.11.1995 @{ub} @{fg highlight} CPUCONTROL IS A CARDWARE PRODUCT PLEASE READ THE 'DISTRIBUTION' SECTION FOR MORE DETAILS.@{fg text} @{u}CONTENTS:@{uu} @{" Introduction " link "Document_1" 0} What's the idea behind CpuControl @{" Features " link "Document_7" 0} CpuControl's abilities in detail @{" Requirements " link "Document_2" 0} What you need to use CpuControl @{" Installation " link "Document_0" 0} Installing CpuControl on your system @{" Usage " link "Document_4" 0} How to use ... @{" Technical Details " link "Document_9" 0} Some stuff for the programmers ... @{" Compatibility " link "Document_5" 0} Successfully tested configurations @{" Author's notes " link "Document_8" 0} Some remarks from me ?! @{" Distribution " link "Document_6" 0} Details about distribution @{" contact " link "Document_3" 0} If you feel the need ... @{" History " link "Document_12" 0} Curriculum vitae @{" Troubleshooting " link "Document_11" 0} If you have a problem with CpuControl @{" " link "Document_10" 0} Features that might be added some day @endnode @node "Document_0" " Installation @{b}Installing CpuControl:@{ub} Installing CpuControl is really no big deal. Just copy the executable to your C: directory or any other directory you might find useful. If you want, you can change the filename into a shorter name. I recommend to replace the original CPU command (as it comes along with the OS 2.0+ distribution), since CpuControl offers the same functionality with somewhat improved capabilities. @endnode @node "Document_1" " Introduction @{b}Introduction:@{ub} CpuControl started some time ago as a programming exercise. The idea was to create a program that uses the advanced features of Motorola's MC68020 and (especially) MC68030 processors like Cache manipulation, MMU code and the enhanced addressing modes. So I decided to do some replacement for the CPU command as it comes along with the Workbench distribution. CPU is a very useful tool, but it could need some improvement, anyway. There were several aspects which I was not quite satiesfied with as the following examples may illustrate: o CPU accepts any command line if only the keywords are valid. Things like CPU CACHE NOCACHE CACHE CACHE FASTROM NOFASTROM ... are processed without problems problems, since CPU executes every option one after another. So the Caches are acticated, disactivated, activated, and so on. This is not really a disadvantage, but I think a good command line parser should reject such crap. o When the FASTROM feature is activated, CPU moves the VectorBase into FastRam in order to improve interrupt handling. This cannot be undone without restarting the machine. o The MMU table used by the FASTROM option is not very efficient (it is larger than it needs to be, I mean). But CpuControl was not intended as a simple CPU clone. Due to the hardware restrictions of my old A2000 I was forced (almost ...) to use the FASTROM feature ever since I got my A2630 accelerator board. This occupies 512K of my precious 32Bit RAM (4MB ain't too much, especially when you have got a graphics board !). The memory loss cannot be helped, but it *should* be possible to use this 512K not only for a simple copy of my ROM contents. So I implemented a real nice KICK option that makes it possible to load and activate another KickStart version (see @{"Features" link "Document_7" 0} section for details). I've been looking for a MMU based SoftKicker for some time, but I found none for my hardware configuration. There's SoftKick for A3000s and Set040 for 68040 based machines, but none for my shitty old A2000 ! The other SoftKickers like SKick and MKick couldn't convince me, either (the Patchtables were not up to date for Kick 3.1). @endnode @node "Document_2" " Requirements @{b}Requirements:@{ub} CpuControl is designed to be used with MC68020/68030 processors (Commodore's [R.I.P.] accelerator boards A2620 and A2630 are perfectly fit). If it is started on a system with a 68000/68010 or 68040, it quits with an error message. At this point you might ask why your MC68040 processor is not supported. Well, the reason is that especially MMU coding is quite different from the '030. Since I don't own a 68040 equipped machine (yet) and the necessary documentation, I am not able to support this processor at the present time. But this is no big disadvantage, because there's a program out there on the Aminet (called Set040) which is especially handcrafted for the 68040, including softkicking of other OS versions. Here's now what you need to use ALL features of CpuControl: o OS 2.04 or better o MC68020 or MC68030 (FPU 68881 or 68882 optional) o MMU 68851 or internal 68030 MMU o 2 MB 32Bit FastMem (the more, the better !) o 512K ChipMemory (notice that a softkicked OS might want more !) o any Chipset (OCS, ECS, AA) Please note that a functional MMU is needed for full functionality. On 68020 systems without 68851 or on 68EC030 (EC = economy ?) systems you can not use the FASTROM and KICK options ! CpuControl is able to detect a missing or non-functional MMU and quits with a warning if you try to use this options. If you want to use the KICK option, you need a valid ROM image that meets the following conditions: o the OS version must be greater or equal to OS 2.04 o the file must contain plain Kickstart data, i.e. no Superkickstart files or ZKick files are supported at the moment o the Kickstart image MUST be fit for your particular system, i.e. you cannot use an A4000 kickfile on an A2000 ! This might change in future releases, although it is not very likely, since it requires heavy patches in the Kickstart code. The easiest way to get a suitable kickfile is to run the 'SaveROM' tool that comes along with this distribution on an Amiga that is equipped with the required ROM version. This tool reads the contents of the installed ROM and writes it into a specified file. Be sure that no FASTROM option is active, because some software might patch the Kickstart in RAM without correcting the checksum (the software of the Piccolo gfx board does so when used with OS 2.xx in order to use 256 colors in the WB emulation). This causes a checksum error when softkicking the OS. IMPORTANT NOTES: THE KICKSTART SOFTWARE IS COPYRIGHTED BY AMIGA TECHNOLOGIES. IT IS ILLEGAL TO USE COPIES OF THE KICKSTART SOFTWARE WITH- OUT PERMISSION OF THE COPYRIGHT OWNER. USING ILLEGAL COPIES OF THE KICKSTART STUFF IS THEREFORE NOT ENCOURAGED BY ME, EVEN THOUGH CPUCONTROL OFFERS YOU THE POSSIBILITY TO DO SO ! THIS DISTRIBUTION DOES NOT CONTAIN ANY KICKSTART FILES. Currently CpuControl does not support OS versions below 2.04 for softkicking, because I think there's no need to use those 1.x versions any longer. Nevertheless, feel free to contact me if you want the ability to softkick 1.x versions to be implemented. Maybe you can even convince me to code a special 1.x version of CpuControl. @endnode @node "Document_3" " contact @{b}How to contact me:@{ub} Here's my address for those who feel like contacting me: Oliver Goss Gnesener Str. 4 93057 Regensburg Germany Unfortunately I don't have an email account, but my good friend Christian (bless him) has allowed me to provide you with his email address so that you can contact me via email. Just put my name in the subject line. christian.rotter@rz.fh-regensburg.d400.de @endnode @node "Document_4" " Usage @{b}Usage:@{ub} CpuControl is a shell-based program, i.e. it cannot be started from the Workbench (you can use 'Execute Command' from the Workbench menu if you don't want to open a shell window). CpuControl supports three different command line templates. Only one valid template can be used at one time, i.e. the arguments of one template must not be mixed with another template. If you use arguments that are not supported by your system, you will receive an error message in some cases, e.g. when the FASTROM option is used on a 68EC030 system. All Cache and Burst related arguments adapt automatically to your system. @{u}TEMPLATE 1:@{uu} CpuControl CACHE/S,NOCACHE/S,DCACHE/S,NODCACHE/S,ICACHE/S,NOICACHE/S, BURST/S,NOBURST/S,DBURST/S,NODBURST/S,IBURST/S,NOIBURST/S, FASTROM/S,NOFASTROM/S,MOVEVBR/S,RESETVBR/S. This command template is similar to the CPU command. It covers most of CpuControl's features. @{b}Switches/Keywords: Function:@{ub} no arguments Reports some status information (Just try it). ? Display some help. CACHE Enable CPU Caches. NOCACHE Disable CPU Caches. DCACHE Enable Data Cache. NODCACHE Disable Data Cache. ICACHE Enable Instruction Cache. NOICACHE Disable Instruction Cache. BURST Enable Bursts (Data and Instruction). NOBURST Disable Bursts DBURST Enable Data Burst. NODBURST Disable Data Burst. IBURST Enable Instruction Burst. NOIBURST Disable Instruction Burst. FASTROM Move Kickstart ROM into 32-Bit RAM (MMU required !) NOFASTROM Remove FASTROM. MOVEVBR Move VBR into 32-Bit RAM. RESETVBR Reset VBR to location $00000000. @{i}Example@{ui}: The command line 'CpuControl CACHE BURST FASTROM MOVEVBR' enables all Caches and Bursts and moves both the Kickstart and the Vector Base into FastRAM, boosting the system performance to the maximum. @{u}TEMPLATE 2:@{uu} CpuControl KICK/A FILE/A This command template is used to softkick a Kickstart file. Please note that the full path to the Kickfile has to be given. A functional MMU is required to use this option ! @{i}Example@{ui}: The command line 'CpuControl KICK Devs:Kickstarts/Kick3.1' tries to load the specified Kickstart and resets the machine afterwards. It is not possible to load the same OS version as it is found in the ROM. If you try to do so, CpuControl just quits, thus giving you the possibility to use it as the first command in your startupsequence, i.e. there's no need to check if the desired OS has already been softkicked. @{u}TEMPLATE 3:@{uu} CpuControl UNKICK/A This command template is used to remove a softkicked OS. All other RomTags remain untouched. Any residents hooked in via ColdCapture or CoolCapture are removed, though. @{i}Example@{ui}: The command line 'CpuControl UNKICK' kills the KICK Romtag and reboots the computer with the ROM Kickstart. @endnode @node "Document_5" " Compatibility @{b}Compatibility:@{ub} CpuControl has been successfully tested on the following configurations. Please note that some features are not available on certain systems. My System: - A2000, 1M Chip memory, 2 x 3.5" floppy drives, Kick 1.3 & 2.04 - A2630 with 4M 32-Bit memory, tuned 68882 with 30MHz - Piccolo Graphics Board with 2M memory - Nexus SCSI with Quantum LP105S and LP52S drives - Flickerfixer (DeInterlace Card) - Vortex GoldenGate 386SX PC-Emulator with 4.5M RAM, external 3.5" HD floppy, Seagate ST3243A harddisk, TARGA SVGA board and serial card. CpuControl seems to work fine with the following MMU based Software: - GigaMem - Enforcer @endnode @node "Document_6" " Distribution @{b}Disclaimer:@{ub} No warranties of any kind are made as to the funtionality of this program. You are using it at your own risk, i.e. the author can not be held liable for data loss or any other kind of damage caused by the use of CpuControl. @{b}Copyright:@{ub} All files in this distribution are Copyright 1995 by Oliver Goss. The author retains all rights to the program. CpuControl is distributed as CARDWARE. If you find the program useful, you are encouraged to send me a nice postcard. Please note that CpuControl is definitely NOT Public Domain Software, i.e. you are not allowed to alter the contents of this distribution in any way (see below !). @{b}Distribution:@{ub} CpuControl may be freely distributed in any way, as long as the following conditions are met: 1. No fees may be charged for its distribution, except a reasonable charge for media and shipping, etc. 2. The distribution must contain all files as provided by me in the original archive. 3. The files contained in this distribution MUST NOT be changed nor be used (complete or in part) in other products. It is permitted to add faithful translations of the documentation to the archive as long as the original documentation is enclosed. 4. CpuControl must not be used in commercial products. If you have a question about the distribution or copyright stuff that is not covered by the above lines, please feel free to contact the @{"author" link "Document_3" 0} :) . @endnode @node "Document_7" " Features Features: CpuControl offers you the following features (random order): o Complete Cache and Burstmode control o FastROM option o Ability to move (and remove) the Vector Base into FastRAM o Smarter Command Line interface compared to stock CPU command o Comprehensive error messages o Nice status message o Ability to softkick any OS version from 2.xx to 3.xx o ColdCapture and CoolCapture vectors are not used o 100% handcrafted 68020+ assembler code @endnode @node "Document_8" " Author's notes @{b}Author's Notes:@{ub} I developed CpuControl to meet my personal needs and thus it might be completely useless to you. However, this piece of software has been released in the hope that some Amiga users have a need for it. So if you use CpuControl from time to time, please drop me postcard. Special thanks go to the following persons: - Christian Rotter for providing his email address - Stefan Thielscher and Peter Simons for their articles 'Generationswechsel' in the AmigaPlus magazine. Especially the MMU related articles were indispensable for the development of CpuControl. - Daniel Zenchelsky for ZKick V3.01. The sourcecode was a great help when I created the KICK option. - Greg Tibbs for SoftBoot V3.31. Again the sourcecode gave me a lot of inspiration ;) . NOTE: CpuControl was in part inspired by sourcecodes from Greg Tibbs, Daniel Zenchelsky and Stefan Thielscher. The code itself is my own design, i.e. no parts have been copied. Nevertheless some resemblance may occur in certain cases. @endnode @node "Document_9" " Technical Details @{b}Technical details:@{ub} This paragraph is intended for the programmers among you. It offers some background information over the implementation of the FASTROM option, the KICK option and some other stuff. The CACHE/BURST/... options are quite simple, so I decided not to bore you with an explanation about how to disable the processor caches etc. ;) . However, this text does not offer much information about how to program the MMU or something like that. That would have been beyond the scope of this documentation. One important feature of CpuControl is its ability to detect the missing or non-functional MMU in an 68EC030 processor. This is not too easy to achieve, since the MC68EC030 has a functional TC register although the MMU itself may be less than functional. Another possibility that has to be considered is a 68020 based system without MMU (as it is the case with most 68020 boards or in an Amiga 1200). The MMU detection code must therefore be able to handle the LINE-F exception caused by the execution of a MMU instruction like PMOVE.L TC,(A0) on 68020 systems without MMU. This is achieved by a small exception handler that redirects the LINE-F vector temporarily to some code that catches the exception and sets an appropriate flag to FALSE. The return address on the supervisor stack is then modified so that the instruction that caused the exception is skipped when the handler returns to the normal program flow. After that the LINE-F vector is restored with its former contents. At this point we know whether MMU instructions can be executed or not. But the fact that a MMU instruction can be executed without raising an exception does not necessarily mean that a functional MMU is available. So we have to perform another test to be sure that the MMU is really functional. Therefore CpuControl sets up a very simple MMU table that maps the whole address space of the processor (4 Gigabyte), using two Early Termination descriptors. Any memory access *should* now set the Used Bit in at least one of the descriptors. If this is the case, we can be (almost) sure that the MMU is functional. However, this test may not be 100% reliable. (The idea for this test has been taken from Stefan Thielscher's FastROM program as published on the AmigaPlus Disk 9/94. Hope you don't mind, Stefan ;) .) If these initial tests have been successfully passed, you are able to use the FASTROM and the KICK option, as long as your MMU is not yet occupied by another program. The principle of the FASTROM option is not very difficult to understand. CpuControl just tries to allocate a sufficient buffer in your FastMem area and copies the ROM contents into this buffer. The buffer is received via AllocMem with the MEMF_REVERSE flag set, i.e. AllocMem tries to allocate the buffer at the end of your FastMem area in order to reduce memory fragmentation since the buffer MUST be aligned to a 32 KByte boundary due to the used pagesize in the MMU table. (NOTE: Ralph Babel writes in his Guru Book that the MEMF_REVERSE option does not work reliably on 2.xx systems. I didn't discover any difficulties with this option, but if you do so, please let me know.) OK, let's go on. The next thing to do is to allocate a small buffer for the MMU table and to generate the necessary translation tree. I used the maximum pagesize of 32 KByte here to get a small MMU table. After that the translation tree is activated and any access to the ROM area at $F80000 is now redirected to the FastMem buffer with the ROM image. Please note that the FASTROM option is useful ONLY on Amigas that are originally based on the 68000 processor like the A500(+), A2000, CDTV. The newer Amiga models already have 32 Bit access to the ROM. Well, there's now only one thing more to say about the FASTROM option. The FASTROM options of CpuControl and the stock CPU command are NOT compatible, i.e. you can not remove a CPU FASTROM with a CPUCONTROL NOFASTROM ! CpuControl recognizes foreign MMU tables since all of its own MMU tables contain a special identification longword. Now we come to the most advanced feature of CpuControl, namely the KICK option. This option required a lot of time and headscratching to be implemeted. It is strongly inspired by the sourcecodes of ZKICK by Dan Zenchelsky and SOFTBOOT by Greg Tibbs, but the implementation is my very own and no code has been copied from the named sources. The KICK option is in part similar to the FASTROM option. The great difference that has to be taken care of is that it is not sufficient to just load another Kick version into a buffer and to redirect the ROM accesses to this buffer as it is done by the FASTROM option. Here we must rebuild *all* system structures according to the requirements of the new Kickstart. To achieve this, we have to reset the computer and force it to enter the restart code in the loaded Kick image. This is far more difficult as it sounds, as I must discover. The greatest problem is that it is not possible to perform a proper warmboot (reset) when the MMU is activated. You may have noticed this when you tried to use exec's ColdReboot routine with an activated FASTROM. I tried to find the reason for this behaviour, but I'm not sure whether my explanation is correct or not. Let me know if you have a better one. The critical instruction in this case is the CPU's RESET command. Whenever this instruction is executed while the MMU is active, the computer crashes. At first I thought that the RESET instruction also disables the MMU, but this is not so according to the Motorola User Manuals. But why does the dratted machine crash when the MMU actually remains activated ? I pondered this for a while and my explanation is the following: The RESET instruction is necessary to reset all expansion boards in the computer. It triggers the _hardware_ autoconfig process that renders the expansion devices temporarily unaccessible until the autoconfig process has been completed. Unfortunately the 32 Bit memory on the A2630 board is an autoconfig memory device and thus the MMU table as well as the loaded ROM image vanishes into thin air for a short period of time during the reset process So what can be done to prevent this ? The easiest way is to just leave out the RESET instruction in the restart routine and to jump directly into the ROM restart code. This seems to work, BUT the expansion devices are not reconfigured when the RESET instruction is left out, i.e. there's no FastRam, SCSI, Gfx board etc. available when the computer reboots into the new OS. This cannot be borne. After some more pondering I devised the following solution: CpuControl hooks a RomTag structure into the system that contains some special reboot code. The RomTags are gathered and executed by the system's boot code after the expansion devices have been reconfigured (this is not so when you use a KickStart version below 2.0x. See Ralph Babel's Guru Book for further details !!!). Before CpuControl restarts the computer it gathers some vital information concerning the installed expansion devices via the expansion.library. This information is stored in the protected RomTag area in ChipMem (ChipMem is non-autoconfig memory, i.e. it is ALWAYS acessible). After that CpuControl restarts the machine. At this point of time the MMU is NOT activated, so that the important RESET instruction can be executed without crashing the computer. Thus your expansion devices are properly reconfigured (by hardware). After that the RomTag is executed for the first time. It sets up a MMU translation tree and activates the address translation to replace the ROM with the loaded ROM image. The RomTag code then jumps directly into the reboot code of the ROM image and restarts the machine once again (without RESET instruction, mind you !). Now the RomTag becomes executed once more. It uses the stored information about the expansion devices to link them into the system again by the use of the expansion.library. This routine also adds all memory boards to the system's MemList. The last thing to do is then to re-allocate the memory area containing the ROM image and the MMU table. After that the RomTag gives the control back to the normal boot code. Now the computer starts up with the new OS and all expansion devices are available again ! The only aftertaste that remains is the ExecBase structure being left in Chip memory. This lowers the system's performance considerably ;) (about 0.5% on my machine). The Restart routines do not use the ColdCapture and CoolCapture vectors and the RomTag is linked into the system in a compatible way, i.e. foreign RomTag structures are recognized and properly queued into the list of KickTag pointers. A kicked ROM image survives crashes and resets as long as the execbase structure is not damaged or destroyed. Well, if you think you need more information about this stuff then contact the @{"author" link "Document_3" 0}. @endnode @node "Document_10" " @{b}To do ... :@{ub} This paragraph contains a list with features I want(ed) to add to CpuControl. It depends on the feedback I get from YOU if these features become implemented in future releases. Any suggestions of functions you want to have added are always welcome. To-Do list (random order): - FORCE switch for KICK option to override an already activated MMU - Kickstart patching to remove errors etc. - enhanced command line parser - Kickstart 1.x support or special 1.x version (maybe) - GUI-based version (maybe) - 68040/68060 support - relocate Execbase to Fastmem - messages have to be localized - FLUSH command to clean up memory @endnode @node "Document_11" " Troubleshooting @{b}Troubleshooting:@{ub} This paragraph is designed to shed some light on common problems you might discover whilst using CpuControl. First of all a list of CpuControl's error messages with hints about what is to be done when you stumble upon such a message: Message: 'Only 68020 and 68(EC)030 CPUs are supported' Meaning: CpuControl discovered a 68000 or 68040+ CPU. Remedy: CASE 68000,68010 -=> buy a turboboard CASE 68040,68060 -=> use Softboot Message: 'Not enough memory for FASTROM option' Meaning: Just what it says. You'll need at least a 512K block (non-fragmented !) FastMem plus some 600 Bytes for the MMU table. I think it's not much use to activate the FASTROM option with less than 2 Megs of FastRam. Remedy: Plug in more memory. Message: 'Cant allocate sufficient memory for KICK option' Meaning: See above. Remedy: See above. Message: 'Cant allocate sufficient memory for the RomTag' Meaning: There's not enough ChipMem available for the RomTag-Code. Less than 2K of ChipMem are needed to install the RomTag, so this message shouldn't appear too frequently. Remedy: Close some windows or screens, stop playing sound modules or samples, remove any backdrop pictures on your WB screen, etc. Message: 'Not enough FastMem for option MOVEVBR available' Meaning: Just what it says. 1028 Bytes are required. Remedy: Stop some running programs. Message: 'Too many arguments' Meaning: What could that mean ??? Ah, yes, you gave too many arguments on the command line. Remedy: RTFM to figure out how to provide a decent command line. Message: 'Invalid argument(s)' Meaning: Obviously some crap was discovered while parsing the command line Remedy: Check your typo ! Message: 'Contradictory arguments' Meaning: You used a nonsense combination of arguments like CACHE NOCACHE. Remedy: Re-think your comand line. Message: 'Missing filename for argument KICK' Meaning: No need to explain ... Remedy: Provide a valid filename (+path) when using the KICK-option. Message: 'You need a functional MMU to use FASTROM' Meaning: Seems like you have a MC68EC030 CPU ! Or your MMU/CPU is defective (or you've discovered a bug in CpuControl's recognition code) Remedy: Replace your CPU or buy another accelerator board. Message: 'A MMU is required to use the KICK option' Meaning: Like above ... Remedy: Like above ... Message: 'Your MMU is already in use' Meaning: Some other program has already installed a MMU translation tree. Check out if the stock CPU command has been executed with the FASTROM keyword or if some other MMU related programs like GigaMem, Enforcer,VMem, etc. have been activated. Remedy: Start CpuControl before any other program that uses the MMU. Message: 'Cant execute NOFASTROM' Meaning: CpuControl discovered that your MMU is activated, but the translation table was not built by CpuControl's FASTROM code. This message appears when the stock CPU command has installed its FASTROM. Remedy: Try to remove the FASTROM with CPU NOFASTROM. Message: 'Cant access specified file' Meaning: The file you named for the KICK option can not be found. Remedy: Check filename and path. Message: 'Invalid KickStart file' Meaning: The file you want to softkick is obviously not a valid ROM image. Remedy: Get a VALID image using the SaveROM program. Message: 'Cant open file' Meaning: The file you named for the KICK option can not be opened. Remedy: Check the file. Message: 'Could not read from file' Meaning: There were errors while reading from the file. Remedy: Check the file for errors. Message: 'Cannot reset VBR' Meaning: The VBR table cannot be removed from FastMem since it was not moved by CpuControl's MOVEVBR command. Remedy: Check if some other program was executed that moves the VBR into FastMem (e.g. CPU with FASTROM option) Message: 'There is already a kickfile installed' Meaning: A kickfile has already been softkicked using CpuControl. Remedy: Kill the softkicked ROM image using CpuControl's UNKICK option and try again. Message: 'Cant open expansion.library' Meaning: Just what it says. Shouldn't happen at all, though. Remedy: ??? Common problems with CpuControl: * Can't remember any at the moment Please report any misbehaviour and malfunctions to one of the given @{"addresses" link "Document_3" 0}. @endnode @node "Document_12" " History @{b}History:@{ub} This part contains an chronological overview of CpuControl's development process with information about changes, revisions, removed and discovered bugs, etc. V0.01 Date: 07/02/95 This revision and all later revisions up to V1.00 remained unreleased due to the fact that they were under constant development. V1.00 Date: 27/04/95 First version with all functions completely implemented. Kicking another OS version works at least on my machine. Nevertheless this release needs extensive testing and a rework in some aspects. This version already works fine with GigaMem and all of my currently installed expansion hardware (quite a lot). Known Bugs: - Any program calling exec's 'ColdReboot' leads to a system deadlock in the reboot process. A keyboard reset revives the system in this case *without* losing the kicked OS ! - A similar problem occurs when the Bootmenu is activated (by pressing both mousebuttons during a reset). A system deadlock occurs after the Menu has been closed. Another keyboard reset revives the system with the manipulations done in the menu taking effect. V1.01 Date: 01/05/95 Slightly improved version. Changes: - 'LVOColdReboot' is set to my own routine when the RomTag is executed. Any program using 'Coldreboot' now triggers a proper reset without system deadlock. The library vector is changed in a (more or less) system friendly manner via 'SetFunction'. Known Bugs: - The Bootmenu still doesn't work correctly. This might be solved by patching the ROM image. V1.02 Date: 02/05/1995 Added options MOVEVBR and RESETVBR to enhance the performance when handling interrupts and exceptions. Improved program info string (option '?'). Known Bugs: - Performance drops sharply (due to SysInfo) when the CACHE option is used. Obviously the Freeze-Bits are set by accident, rendering the caches useless (Aaarrrrrgh). V1.03 Date: 03/05/1995 Performance loss when using CACHE option has been corrected. No further Bugs have been corrected :( . V1.04 Date: 04/05/1995 'MMU Status' string now displays information about the current MMU user. Only CpuControl's own MMU tables are currently recognized, all others are titled 'unknown user'. Again not much improvement :( . V1.05 Date: 08/05/1995 Changes: - Patching of _LVOColdReboot via 'SetFunction' has been removed since it didn't work at all when using the Bootmenu. Now the ColdReboot code in the Kickfile is manipulated to meet our needs. Result: Bootmenu works fine now ;) . To do: - Command line parsing while using templates 1 & 2 needs some rework. At least one additional switch has to be implemented for the KICK option. V1.06 Date: ??/??/?? @endnode